fix(libScePad): return 0 from n3kSX62fgNo after scePadInit, with a pad open or not - #7908

What

scePadUnknown_n3kSX62fgNo now returns 0 after scePadInit, whether a pad is open or not. Before scePadInit it still returns 0x80920005, now through PAD_ERROR_NOT_INITIALIZED. I removed the throw while a pad is open, and the two PAD_UNKNOWN_N3KSX62FGNO_* constants with it.

The source is a static analysis of the OS 10.01 system module (libScePad.sprx, plus libSceMbus.sprx for the function it calls). At pseudocode level:

int32_t n3kSX62fgNo(void)
{
    if (!initialized) return 0x80920005;
    return mbus_set(1) == 0 ? 0 : 0x809200FF;
}

• It takes no arguments. It reads no pointer and takes no lock. It does not touch the handle table or any pad state, so scePadOpen makes no difference to it.
• mbus_set is the unnamed libSceMbus export 0mRAu1IWNEA, a thin IPMI client call to ShellCore: method 0xCE110066 with the payload {1, getpid()}, returning the server's result. libScePad is its only importer in the OS 10.01 system modules, and this is its only call site. So the pad function sets a per-process value to 1 in ShellCore. The server side is not part of what I analysed, so what that value controls is unknown.
• Any error from that call becomes 0x809200FF.

This matches the console probe in #3177 (comment, PS5 system software 13.60): 0x80920005 before scePadInit, 0x809200FF after it, no byte of the rdi buffer changed, and no fault on NULL or guard-page pointers. That probe ran in a payload that is not a game process (sceUserServiceInitialize failed there too), which is where a ShellCore call would be refused. In a game process I expect ShellCore to accept it, so the function returns 0. That last step is inferred, not measured on a console, and the debt entry says so.

Thanks to MarcZX10 for #5676, which put the measured statuses on main, and to everyone in #3177 for the console probe. #5676 kept the throw for an open pad because the probe could not open one; the system module shows that an open pad does not change the result.

Debt: I cut the n3kSX62fgNo entry to what is still open (name unknown, the 0 inferred, the ShellCore setting not modelled) and removed the older entry at the end of libScePad.md, which still said the function throws. The name is still unknown, so the export keeps scePadUnknown_n3kSX62fgNo.

Overlap: #5038 also changes this function (it returns 0 unconditionally, before scePadInit too). It conflicts with main since #5676, and a reviewer asked there to drop this function from it. My other libScePad pull request (scePadGetAccessibilityControllerState, zBsgF0q8DIM) touches the same three files; the two merge cleanly in either order.

Tested

Windows 10 (19045), WinLibs GCC 15.2.0, Release, Ninja, main f3bb6a4 plus this commit:

• ctest -R "^guest_pad": guest_pad and guest_pad_vibration_mode pass.
• guest_pad now checks the four states: before scePadInit (0x80920005), after scePadInit (0), with a pad open (0, no throw) and after scePadClose (0).
• With main's Export.cpp and this test, guest_pad aborts at the first call after scePadInit, where main returns 0x809200ff. With a pad open, main throws scePadUnknown_n3kSX62fgNo not implemented, which the old test asserted.
• python tools/check_conventions.py --base origin/main with this title and body passes.

I have not run any of the titles below.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• Fixes: none
• Unblocks: PPSA15645, which calls it with a pad open and stops there on main (#5676 comment, #3965 comment). The other titles reported to import it get 0 instead of 0x809200FF after scePadInit: PPSA13356 (Exports for PPSA01530, PPSA23827 and PPSA13356 imports #3177 1, 2; does not read the result), PPSA01530 Puyo Puyo™ Tetris® 2 (PPSA01530) #6421 and PPSA23827 (Exports for PPSA01530, PPSA23827 and PPSA13356 imports #3177, fix(exports): export the calls PPSA01530, PPSA23827 and PPSA13356 import #3337), PPSA07411 (#2776 comment), PPSA01317 Gran Turismo 7 (PPSA01317) #4697 (listed in libScePad: replace NotImplemented stubs and fix return-0 consistency #5038). I have not run any of them.
• GPUs tested: n/a
• AI-assisted: yes